Orchestration

The way Blue Prism Cloud utilizes orchestration is by leveraging the IADA service within a Blue Prism process called Orchestrator, the Orchestrator process will perform all the logic and intelligent decision making on which process to run; and when to run that process. The Orchestrator process will be running throughout the day, all day (aside from a small automation maintenance window), consuming all your digital workforce or as much as you want to allow it to utilize.

Implementing orchestration will allow you to use more advanced decision making, leveraging Blue Prism Cloud IADA service and Orchestrator process will ultimately allow you effectively utilize your Blue Prism Cloud Digital Workforce in the best way possible.

What is orchestration?

As we explained, within an organization not all process automations and their associated items have the same value to the organization, some business processes need to be prioritized over others. By default, items will simply be addressed and processed in a First-In-First-Out (FIFO) methodology.

This combined with the fact that there can be multiple queues with the Blue Prism Cloud Digital Workforce that need to be managed, means that work can get stalled in handling an individual queue or stuck processing automations with work items which are of a lower value.

IADA maintains, in effect, its own view, looking across not a single queue but all the queues and assessing assigned values (such as business priorities and SLAs), it will determine the next automation item that needs to run, whilst queuing the next best value item ready for execution by the next available digital worker.

For an automation to be given a priority over another automation, it has to be configured with a business priority and an SLA. There are multiple ways of adding these parameters into your automations and we will show you how in more detail later. This is the key element so when items are added to the work queue, the business metrics are added along with the process.

Key definitions

For clarification, lets define some key terms we use throughout this user guide:

Business priority

The business priority value must be above zero. The lower the value, the higher the business priority (e.g. a business priority value of 1, will be processed before an item with a business priority value of 2). This business priority value will override the SLA value.

IADA accepts a business priority value between 1 to 999.

Business SLA

The business SLA value is a timespan. This should be the amount of time that the work queue item should be completed and processed within. The SLA timespan value will then be used within the IADA algorithm to produce an SLA Datetime.

IADA accepts a business SLA in the format of DDD.HH:MM:SS (Days, Hours, Minutes, Seconds) e.g. 01.04:30:00 = 1 Day, 4 Hours, 30 Minutes, 0 Seconds. The minimum SLA is 1 second, the maximum SLA is 999 Days, 23 Hours 59 Minutes and 59 Seconds.

Environment locks

In order to ensure that there are no conflicts when reading from or writing to the queue item, environment locks are used.

Environment locks are used quite heavily within orchestration, as they are key to adding a control mechanism for decision making when getting the ‘Get Next Best Item’ to be worked via IADA.

Tag identification

This is a unique GUID that is assigned to a work queue item by the ‘Get Next Best Item’ function to allow the Executor function to correctly identify the work queue item for processing.

SLA timespan

If the Priority assigned to two items is the same, then the timespan before the SLA expires is used to determine the order in which items are processed. This is calculated from when the item is added to the queue and the current time.

For example, two items added to a queue with the same priority and different SLAs:

• Item A – Priority 10 – SLA 00.01:00:00 (1 hour) – added to queue at 09:30;
• Item B – Priority 10 – SLA 00.01:30:00 (1 hour 30 mins) – added to queue at 08:45.

If the current time is 10:00, then Item A has 30 mins remaining on its SLA timespan whereas Item B has only 15 mins remaining on its SLA timespan. Therefore, even though Item B has a longer SLA, it will be processed before Item A.

Whitelists and blacklists

IADA orchestration supports the use of whitelists and blacklists for the processes and queues used within orchestration.

The values set determines the action that the ‘Get Next Best Item’ function within the Orchestrator process performs, for example for the queue lists:

Flag State	Content	Description
True	Queue A and Queue B	Orchestration will only look for items with a Tag Identifier in Queue A and Queue B.
True	empty	Orchestration will look across all Queues for items marked with a Tag Identifier.
False	Queue A and Queue B	Orchestration will look across all items with a Tag Identifier in all queues, except for items in Queue A and Queue B.
False	empty	Orchestration will look across all Queues for items marked with a Tag Identifier.

How does orchestration work?

Before looking at the Orchestrator process operation, it is good to have a basic understanding of IADA and how the service is called.

IADA service

The IADA service is delivered as an Azure ‘function app’ within your Azure subscription. This is to ensure security and integrity of service.

The Azure function app is built with two standard functions:

• Add to Queue
• Get Next Best Item

These functions are called via a Blue Prism RESTful web service which interacts with the IADA function app.

The IADA function app stores information relevant to orchestration in a dedicated IADA database. This database is an Azure SQL database held within your subscription.

The diagram below illustrates a typical data flow when using the ‘Add To Queue’ functions.

When the ‘Add To Queue’ function is called, the data item is added into the IADA database as well as the Blue Prism RPA database where it can be seen in the relevant Blue Prism queue.

To improve the performance of IADA orchestration, the ‘Get Next Best Item’ function reads from the IADA database to look for the next item most suitable for processing. This takes the orchestration load off the Blue Prism database. The Blue Prism queue is updated to include the Tag Identifier and mark it as complete once the item has been processed. This is illustrated in the data flow for ‘Get Next Best Item’ function below.

Orchestrator process

In a typical environment, the Orchestrator process would run continually on some digital workers, whilst other digital workers will be dedicated to performing the Collector process. Typically, the Orchestrator process runs and operates the same way across the digital workforce environment, except for those specified as Collectors.

It is recommended that the digital workers running the Orchestrator process are identical, with each digital worker capable of running every process.

The dedicated Collector digital workers use the ‘Add To Queue’ function to load work items into their respective queues.

1. The ‘Add To Queue’ function adds items to queues one by one.

   This is different to the Blue Prism ‘Add To Queue’ which performs this task in bulk. The reason for the singular approach is to allow an item to be added with a specific priority and SLA rather than all items with the same priority and SLA.

   If the item is added to a queue using the standard Blue Prism ‘Add To Queue’ it will NOT get written into the IADA database and therefore will not be considered for orchestration. Only items added into work queues using the IADA ‘Add To Queue’ function or via Interact with a defined priority and SLA will be considered for orchestration.

2. The Orchestrator process performs several steps:

   1. It acquires a lock for a digital worker.
   2. It runs the ‘Get Next Best Item’ function to identify the work item most suitable for processing, determined by the highest priority and the lowest SLA timespan.

   The ‘Get Next Best Item’ function builds a collection using the information retrieved, with the following three parameters; Process Name, Queue Name and Tag Identifier. The Tag Identifier is a GUID, which is unique to the item, to mark it for execution. This GUID is also applied to the Blue Prism queue item to show the specific item within the specific queue during processing. The environment lock on the digital worker is then released.

3. The Orchestration control page of the process takes the built collection, acquires another environment lock and checks to see if the process to be called has just been run and is therefore still active. This is to save time in relaunching applications if they are still active and can be reused.
4. The Orchestrator process moves to the Process Control page to run the required process, releasing the environment lock before calling the Executor for that process. The Tag Identifier and the Queue Name is passed to the Executor from the built collection ensuring that the specific item with the highest priority and lowest SLA timespan is executed.
5. After the item is processed the GUID (Tag Identifier) is removed from the queue item and the item is marked as complete.

If the execution of the process results in a business exception, this should be handled within the actual business process and the item in the queue marked with an exception rather than completed.

Within the Orchestrator process there is a dedicated page to manage ‘consecutive system exceptions’. This page provides a counter for when networking or failed digital workers cause an exception to the running of the process. By default, the maximum limit counter is set to three. The counter is set at ‘0’ and incremented when a consecutive exception occurs. If there are three consecutive exceptions of the same system exception, the Orchestration process is halted.

Whilst this is happening on one digital worker with its own Orchestrator process, other assigned digital workers with their respective Orchestrator processes will be performing the same task on work items, ensuring they are getting processed in priority and SLA order.

The Orchestrator process continually runs and will continue to check to see whether there are items with an associate priority or SLA that needs to be processed.

As the Orchestrator process continually runs, it is recommended that the Orchestrator process is ‘paused’ once a day to allow maintenance work to be performed on the digital worker. This could include items such as reboots of digital workers and upgrades.

It is recommended that the Orchestrator process is run across specific digital workers within the workforce, whilst other digital workers are allocated the task of Collector or set aside to perform specific scheduled tasks. If a process has to be run at a specific time and is scheduled, it should not be included in the Orchestrator process and dedicated digital workers should be assigned to perform scheduled tasks.

Items will only be processed by the Orchestrator process, even if they exist in the IADA database, if the Queue and Process lists apply. See the definition on Whitelists and blacklists for more details.

Adding priority and SLA to queue items

There are several ways to add the priority and SLA to queue items. The main way is discussed in the section above, which is the ‘Add To Queue’ IADA function.

When using the ‘Add To Queue’ function you must stipulate a Priority and SLA, you cannot supply ‘null’ values. So this action cannot be used to add an item to a queue without a priority and SLA assigned.

The other main way to add items to the queue with priority and SLA is through Interact. When a form is created within Hub, you can stipulate the priority and SLA that the form will use when submitted.

Within the form creation you can decide whether to include these parameters or not. If they are:

• Not included, the submission is not added into the IADA database just the Blue Prism queue.
• Included, the submission is added to both the IADA database and the Blue Prism queue.

The ‘Find Next Best Item’ function will only consider items in the IADA database and items only get added into this database when they are assigned a priority and SLA.

Designing for orchestration

When implementing orchestration, it is common to feel apprehensive when considering how to approach the design, and it is sometimes thought that complex cognitive systems and Artificial Intelligence (AI) are required to complete the design.

Although cognitive systems like Machine Learning (ML) and AI implementations are important, it should be a secondary consideration after implementing a Logical and Algorithmic design. These technologies need to overlay a base foundation of logical decision making.

Logical decision making

Once you break down the requirements, you can start to understand what checks the process might want to perform when deciding whether an automation is suitable for orchestration. You should check each process in turn and consider the following:

• Does it need to run at a specified time?
  • This is important and should be one of the first checks that is performed. If the process automation has to be run at a specific time of day, and must be run at that time, then it may not be suitable for orchestration.
• What is its priority?
  • Where does this fit within the priority list compared to other process automations. Planning the priority list is a key factor to ensure that processes are added in the correct business order. We recommend that you do not set priorities as 1, 2 and 3, but start maybe in 10’s or even in 100’s. So, setting the highest priority with a 10 for example now, will allow you to still add a higher priority item at a later date without needing to adjust existing processes.
• What is its SLA?
  • Does the process, once initiated, need to be completed within a specific time frame? If so the SLA should be set to ensure that the item is added to a queue with a defined timeframe. This also needs to be in conjunction with an assigned priority to ensure that it gets the required attention.
• Are there processes and queues that either need to be specifically included or excluded?
  • Plan the whitelists or blacklists appropriately. Considering whether orchestration is only going to run on specific queues or all queues, or on all queues but a specific few. Then set the queue list appropriately to meet the business requirements. Repeat this for the list of processes to ensure that processes are either included or excluded from orchestration as appropriate.
• Can the business process be segregated into launch/login and execution?
  • For each business process added into orchestration, we need to look at whether the automation process can be segregated into a launch/login step and a standard execution stage. This will enable more efficient processing, especially if the application takes a long time to launch. The Orchestrator process will look to see if the last application it ran is still running and then will use that application without needing to relaunch and login back in again. If it is not, the same process it will terminate the previous application and launch the new application.

The same level of understanding and questioning should be performed for all processes to check suitability for orchestration.